Codecov Report

Merging #5058 (2519702) into master (29e992f) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #5058   +/-   ##
=======================================
  Coverage   84.74%   84.74%           
=======================================
  Files         286      286           
  Lines       60036    60037    +1     
=======================================
+ Hits        50876    50880    +4     
+ Misses       9160     9157    -3     

We don't support win-32. I wouldn't have too many badges, it looks really spammy and it's easy to go overboard. The version badge IMO is pointless, because is easy to see on the GH page, where it shows the latest tag. The license badge would be nice to have, so it's obvious how it's licensed without having to go into the actual LICENSE file.

PyPi download count is not really informative for the user, IMHO.
Neither is open issue count.
Version I don't mind, but one can indeed easily spot it.

Also in favour of not having too many. Just relevant (informative) ones.

We don't support win-32.

Conda apparently thinks we do.

Keep in mind, when a non-GitHub-savvy user sees our page, their eyes focus in on the README, if we're lucky. That's why it's nice to have the information we deem relevant there, even if it leads to redundancy.

I'd love to include a shields for all the docs we have (throughout the README), but that'll have to be part of a bigger README redesign.

Conda apparently thinks we do.

conda-forge is the reason we don't. They were the ones who dropped support in 2019 Q2: conda-forge/staged-recipes#5640, #3939. We just followed suit.

https://anaconda.org/conda-forge/orange3

Ah, technically we support it with v3.13.0.
(the shield in OP is automatically generated with info from conda-forge)

For me, the relevant ones are the latest version, perhaps a link to docs or to chat, and a download link to our webpage - only those, as someone wrote up there, that would help users.

I would actually remove ones meant for the developers (test status, coverage).

I would actually remove ones meant for the developers (test status, coverage).

I'm inclined to agree. I suppose it imbues the user with some confidence in your product if you have good coverage and your build is passing? I'd think most non-developers wouldn't even think to question it.

Then again, GitHub is somewhat a social network for developers. But since we use GitHub as our issue tracker, our README must target both non-tech-savvy (our primary target userbase) and developer audiences.

Currently, our development workflow and documentation are very well hidden from sight, I myself didn't know about most of it up until recently. This makes it hard for anyone outside the Biolab bubble to join as a developer, even though we're an open-source project.

Right now, from what I can tell, in support of extending the community, we provide good first issue tags, and a CONTRIBUTING.md file. The latter is only relevant when a user first attempts to make a contribution, they're shown it as such:

I have a lot of good first issues noted down, but if I were to post them all on the issues page, it would be flooded. I suppose if we were to change our workflow to accommodate attracting more external contributors, we would switch to a GitHub board for meetings.

The first thing anyone looks at when their interest is piqued is our README. I'm thinking of restructuring it as follows, interspersed with text, of course:

Intro (aimed at laymen)

• A bigger image, such as the one on the main page
• Version, Download, Orange Visual Programming docs, Chat shields. I'd love to include a downloads shield here too for clout, but not just PyPi numbers.
• A screenshot of Orange GUI

Contributing (aimed at developers)

• Build, coverage shields (+ # of contributors shield, commits/month shield?). The purpose of these shields is to tell people that the project is well, alive, and active
• Explanation of orange3, canvas-core, widget-base (i.e., if you want to contribute UX/UI improvements, look at canvas-core), perhaps link to first-party add-ons too
• Development docs shield + link to contribution guidelines
• "Good first issue" issues shield
• Invite to join Discord (chat shield, again)
• Step by step guide on setting up Orange in development (making sure pip install -e ./python setup.py develop is clearly conveyed)

Installation

• Download shield (again)
• (as is, but should this deviate as much as it does from Orange's download page?)

Another (somewhat related) thing, we should look into committing PyCharm run/debug configurations, it'll be easier for people to get started on Orange with an IDE.